場景：一段看起來很專業的廢話

準備一場圈報告討論時，我在螢幕上打開順安圈的結案報告，想試試 AI 能不能先幫團隊整理審閱重點。

順安圈是 7B 病房那幾個人組的品管圈。這種報告一年會進來很多份，那一份不算難，只是我已經看了一整天。

於是我做了一件當下覺得很聰明的事：把整份報告貼進對話框，打了四個字。

幫我看看。

三十秒後，螢幕上出現一段文字。分段清楚、語氣專業、用詞全部是對的——它談到主題選定的合理性，談到現況把握的完整度，談到對策的可行性，最後收在一句「建議可再強化數據佐證與效果的持續追蹤」。

讀起來毫無問題。我甚至有一瞬間覺得，這比某些委員手寫的評語還工整。

然後我盯著它看了兩分鐘，發現一件事：

這段話貼在任何一份品管圈報告底下，都成立。

換一份報告，那段話不會變。它的輸出跟輸入無關——那不是一個 function，是一個常數。

而一個跟輸入無關的輸出，連 unit test 都寫不出來：沒有任何一組輸入會讓它變。

隔天我念給小葉聽——他進品管室兩年，複核都是他在跑。他抬頭說：「這聽起來像我們每次都會講的那句話。」

對。而那正是問題。

「幫我看看」不是一個任務

品管室看一份結案報告，看的不是「寫得好不好」——這個問題沒有答案。實際在看的是一組具體的東西：

• 主題選定的理由站不站得住，還是為了做而做
• 現況把握有沒有真的量過，還是憑印象寫的
• 要因分析是停在現象，還是真的往下挖了一層
• 對策擬定有沒有接回前面分析出來的要因，還是中途換了一組新的；以及對策的強度夠不夠（這件事 Day 13 整篇談）
• 效果確認用的量法，跟現況把握時是不是同一套
• 標準化那一章寫的是「以後誰、在什麼時候、照什麼做」，還是一句「已納入教育訓練」就收掉

（這六個是品管圈報告的固定章節：主題選定 → 現況把握 → 要因分析 → 對策擬定 → 效果確認 → 標準化。翻成人話：為什麼做這題 → 做之前量到什麼 → 為什麼會這樣 → 打算怎麼改 → 做完再量一次 → 有效的話怎麼固定下來。最後一章是最常被寫成一句話帶過的一章，Day 27 會回來算這筆帳。）

這幾條在品管室內部是有共識的。委員之間會吵，但吵的是這把尺上的刻度——同一條對策，有人給「勉強可以」，有人給「這不算對策」。我們吵的永遠是 nit 還是 blocker，不是要不要審。

那這把尺怎麼在人跟人之間傳下去？它是一份沒有被 commit 過的 review checklist。 它的傳承方式不是文件，是跟著資深委員看過幾十份、在會議上被問過幾次「你憑什麼這樣說」、被退過幾次——shadowing，不是 onboarding。

Day 1 說過，這類判斷停在判準的形式化極限的右邊。那天講的是這條線存在。今天講的是我第一次撞上它的時候，撞法有多蠢：

我沒有把尺交出去，就問它量出來是多少。

我以為我在測模型，其實我在測我自己

翻成你熟悉的語言。

我打的那句「幫我看看」，等於對一個剛到職第一天的工程師說「幫我做個系統」。他不會拒絕。他會做出一個東西。那個東西會有登入頁、會有設定畫面、會用你們公司的技術棧——每個細節都很像那麼回事，但它不是你要的，而且你沒辦法說他做錯了，因為你根本沒說過你要什麼。

我拿到的就是這個。不是一個錯的答案，是一個沒有辦法被判定為錯的答案。

「建議可再強化數據佐證」——這句話你要怎麼反駁？它沒有對應到任何一條判準，所以它既不對也不錯。它只是存在。

於是這一篇真正想講的是：

沒有 spec 的自動化，產出的不是錯誤，是無法被驗證的東西。

錯誤在流程裡是有位置的：你標記它、修它、記錄它下次別再犯。品管室處理一份有問題的報告也是同一套。無法被驗證的東西沒有位置，它只能被「參考」——而「參考」是流程裡的黑洞。它進得來，但它不承擔任何後果，也不能被追究。一條裡面有黑洞的流程，跑再多次也不會變好。

這件事在做系統的人身上有一個更短的說法：沒有驗收條件的需求單，交回來的東西你也沒辦法退。

spec 這個字我用得很認真

我不是在打比方。一份能用的 spec 有三個部分：要做什麼、什麼叫做做對了、做不到的時候該回什麼。

「幫我看看」只有一個模糊的第一項，第二項空白，第三項連想都沒想過。而市面上談 prompt 的文章，也幾乎只在寫第一項——怎麼把任務描述得更清楚、角色設定得更精確、範例給得更漂亮。第一項當然重要，但它不是自動化的門檻。

門檻在第二項。 因為第二項決定的不是模型答得好不好，而是你有沒有能力知道它答得好不好。少了第二項，你就只能靠「讀起來合不合理」來驗收——而「讀起來合不合理」正是這一整篇在講的那個陷阱。

第三項則決定這條流程能不能無人跑完一輪。 人遇到答不出來的題目會空著、會來問你；模型預設會填。你不明講「填不出來要說填不出來」，它就會填。

而第二項正是這個系列的軸落腳的地方。規則寫得下來的事，第二項幾乎是免費的——編譯器會告訴你，測試會告訴你，型別會擋在那裡。規則寫不下來的那一半，第二項要你自己從頭寫，而且寫完之後沒有任何工具能幫你檢查你寫得對不對。

我那天晚上對著那份結案報告，以為自己在做的是第一項。實際上我卡住的地方，從頭到尾都在第二項。

第二次，我把尺交出去

第二次我換了做法。不是把整份結案報告丟進去問一句，而是一次只問一件事，而且把判準跟著問題一起交出去——與其說是換了 prompt，不如說是補上了那份缺席的 spec。大概像這樣：

任務：判斷這一條對策屬於哪一個強度層級。
層級定義：
  強效——對策改變了系統本身，讓這個錯誤做不出來，或做出來會當場被擋下
  中效——對策多加了一道人為關卡，錯誤仍做得出來，但比較容易被攔下
  弱效——對策只作用在人的記憶或意願上，系統本身沒有改變
輸出：
  1. 層級判定
  2. 依據——引用報告中支持這個判定的原文
  3. 若報告中沒有寫到判斷所需的資訊，回答「未提及」，不要推測

輸出立刻變成另一種東西。從「一段評語」變成「一組可以逐條對照的判定」。

但真正變的不是模型那一端，是我這一端：現在我有東西可以說它錯。

這句話聽起來很小，實際上它是整條線上最貴的一件事。

最後一列是關鍵。「幫我看看」的產出是一個終點——除了人再讀一遍之外，它接不到任何東西。給了判準之後的產出是一個中間格式，它可以被數、被排序、被跟上個月比。

一段流程能不能自動化，看的不是這一步能不能交給模型，是這一步的輸出能不能接到下一步。

它不是不會，是你沒說

那句「幫我看看」的失敗，最值得記的不是它答得不好。會自己告警的失敗是最便宜的失敗——如果它胡言亂語，我五秒鐘就丟掉了，這一篇也不會存在。

問題是它答得剛好夠好。

這裡有兩個型態，接下來的 30 天會一再遇到。

型態一：它會用你的行話回答你

我用品管圈報告的詞彙提問，它就用同一批詞彙回答。「現況把握」「要因分析」「效果確認」——每個詞都用在對的位置上，語法完全正確。

但詞彙用對不等於判斷做對。

對一個領域外的人，語法正確＋術語到位＝看起來很懂。醫療的行話密度特別高，所以這件事在這裡特別便宜——一段術語全部到位、讀起來很專業的病歷或報告，可以完全沒有臨床內容。現場的人天天在讀這種東西，所以我們對它有抗體；第一次讀到的人沒有。

它不懂。它只是很會講。

更麻煩的是，這種產出消耗你的信任額度但不提供訊息。訊噪比就是這樣掉下去的：你讀了三份都覺得「嗯，還可以」，第四份就不會那麼仔細讀了。

型態二：沒有判準的時候，它會自己補一個

這是整件事最重要的一個發現。

模型不會因為你沒給判準就拒答。它會補一個判準——它補的不是隨便一個判準，它補的是 base rate：語料裡「一份品管圈結案報告最常被建議的東西」。

「建議可再強化數據佐證」不是它讀完那份報告得出的結論。那就是 base rate 本身。

換句話說：

你以為你在問這一份，它回答的是所有份。

這個型態的麻煩之處在於它有方向。它不是隨機亂答，它穩定地往「這一類文件的通則」偏。所以它在抽查裡永遠會過——通則本來就大致成立。要到你需要它分辨「這一份跟其他份哪裡不一樣」的時候，才會發現它從頭到尾沒有在看這一份。它錯的是尾巴，而品管只做尾巴。

而分辨差異，正是品管唯一在做的事。我們不需要知道「品管圈報告普遍有什麼問題」，那個答案在教科書裡。我們需要知道的是這一份、這個單位、這一次，跟平常不一樣的地方在哪——品管在做的其實是監控：通則是背景，偏離才是訊號。

兩個型態疊在一起的時候

單獨看，這兩個型態都不算致命。真正的問題是它們會疊起來。

用對的行話，講的是母體的通則——組合起來就是一段聽起來像資深委員、實際上在描述所有人的文字。

而這種東西在會議上有特殊的殺傷力，因為它精準命中所有人對「一句中肯的評語」的預期：有專業感、不偏頗、不得罪人、聽完會點頭。沒有人會在會議上反駁它，因為它沒有立場可以反駁。

一個判斷系統最該產出的是立場。它產出了氛圍。

所以那之後我改了三件事

不是技巧，是原則層次的三件事。

一、一次一個判準，不要複合問句。 「這份報告的分析深度和對策強度如何」是複合問句，它的失敗沒辦法定位——你不知道它是哪一項判錯了，也沒辦法只重跑錯的那一項。

二、要求輸出的形狀，不要只要求輸出的內容。 判定、依據、把握程度，三欄。「依據」那一欄是重點：它逼模型把判斷掛回原文，而不是掛回語料。掛不回去的時候，你會直接看到它掛不回去。

三、給它一個「沒有寫」的選項。 這條最容易被忽略。當一份結案報告根本沒寫效果確認的量法，而你的問題預設了有，模型會生一個出來。不是它想騙你，是你的問題形狀裡沒有「不存在」這個答案的位置。

為什麼不乾脆一次要它全部輸出

有一條路我試過然後放棄：把整份結案報告丟進去，要求它一次輸出結構完整的完整評估，所有項目一起給。

看起來更有效率，實際上有一個致命問題：失敗會整批發生。

錯一項跟錯八項，在輸出上長得一模一樣——都是一份格式正確的表。而且我沒辦法只重跑錯的那一項，一重跑就是整份重來，重來之後其他幾項可能又變了。

拆成單項慢，也比較貴。但壞掉的時候壞得局部。

批次換到的是吞吐，付掉的是失敗的粒度。差別只在於，在我這裡，失敗的粒度直接決定這條流程驗不驗得起來——而驗不起來的流程，團隊不會用。

拆開之後才有辦法談下一件事：重跑、比對、統計哪一條判準最常出錯。那是把一次性問答變成一條流程的起點。

不過在談流程之前，還有一件更前面的事得先解決：這些東西到底可以丟去哪。明天講工具箱與邊界。